To  Appear  in  Proceedings  of  the  2000  Heterogeneous  Computing  Workshop,  May  2000. 


Toward  Quality  of  Security  Service  in  a 
Resource  Management  System  Benefit  Function 


Cynthia  E.  Irvine  Timothy  E.  Eevin 

Department  of  Computer  Science  Anteon  Corporation 

Naval  Postgraduate  School  2600  Garden  Road 

Monterey,  CA  93943  USA  Monterey,  CA  93940  USA 

email:  irvine@cs.nps.navy.mil  email:  levin@cs.nps.navy.mil 


Abstract 

Enforcement  of  a  high-level  statement  of  security  policy 
may  be  difficult  to  discern  when  mapped  through  func¬ 
tional  requirements  to  a  myriad  of  possible  security  ser¬ 
vices  and  mechanisms  in  a  highly  complex,  networked 
environment.  A  method  for  articulating  network  security 
functional  requirements,  and  their  fulfillment,  is  presented. 
Using  this  method,  security  in  a  quality  of  service  frame¬ 
work  is  discussed  in  terms  of  “variant”  security  mecha¬ 
nisms  and  dynamic  security  policies.  For  illustration,  it  is 
shown  how  this  method  can  be  used  to  represent  Quality  of 
Security  Service  (QoSS)  in  a  network  scheduler  benefit 
function^. 


1  Introduction 

Several  efforts  are  underway  to  develop  middleware 
systems  that  will  logically  combine  network  resources  to 
construct  a  “virtual”  computational  system  [4]  [7]  [8] 
[15]  .  These  geographically  distributed,  heterogeneous 
resources  are  expected  to  be  used  to  support  a  heteroge¬ 
neous  mix  of  applications.  Collections  of  tasks  with  dispar¬ 
ate  computation  requirements  will  need  to  be  efTciently 
scheduled  for  remote  execution.  Large  parallelized  compu¬ 
tations  found  in  Telds  such  as  astrophysics  [14]  and  meteo¬ 
rology  will  require  allocation  of  perhaps  hundreds  of 
individual  processes  to  underlying  systems.  Multimedia 
applications,  such  as  voice  and  video  will  impose  require¬ 
ments  for  low  jitter,  minimal  packet  losses,  and  isochronal 
data  rates.  Adaptive  applications  will  need  information 
about  their  environment  so  they  can  adjust  to  changing 
conditions. 

User  acceptance  of  these  virtual  systems,  for  either 
commercial  or  military  applications,  will  depend,  in  part, 
upon  the  security,  adaptability,  and  user-responsiveness 
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provided.  Several  of  the  projects  engaged  in  building  the 
middleware  to  create  these  networks  are  pursuing  the  inte¬ 
gration  of  security  [6]  [10]  [23]  and  quality  of  service  [1] 
[17]  into  these  systems.  The  need  for  virtual  networked 
systems  to  both  adapt  to  varying  security  conditions,  and 
offer  the  user  a  range  of  security  choices  is  apparent. 

In  the  network  computing  context,  users  or  user  pro¬ 
grams  may  request  the  execution  of  “jobs,”  which  are 
scheduled  by  an  underlying  control  program  to  execute  on 
local  or  remote  computing  resources.  The  execution  of  the 
job  may  access  or  consume  a  variety  of  network  resources, 
such  as:  local  I/O  device  bandwidth,  internetwork  band¬ 
width;  local  and  remote  CPU  time;  local,  intermediate 
(e.g.,  routing  buffers)  and  remote  storage.  The  resource 
usages  may  be  temporary  or  persistent.  As  there  are  multi¬ 
ple  users  accessing  the  same  resources,  there  are  naturally 
various  allotment,  contention,  and  security  issues  regarding 
use  of  those  resources. 

The  body  of  rules  for  resolving  network  security  issues 
is  called  the  network  security  policy,  whereas  the  body  of 
rules  for  resolving  network  contention  and  allotment  com¬ 
prise  a  network  management  policy  (which  is  sometimes 
taken  to  include  the  network  security  policy).  These  poli¬ 
cies  consist  of  broad  policy  jurisdictions,  such  as  schedul¬ 
ing,  routing,  access  control,  auditing,  and  authentication. 
Furthermore,  these  jurisdictions  can  be  decomposed,  typi¬ 
cally,  into  functional  requirements,  such  as,  “users  from 
network  domain  A  must  not  access  site  B,”  and  “user  C 
must  receive  a  certain  quality  of  service.”  The  network 
management  and  security  policies,  as  mapped  through  the 
functional  requirements,  may  be  manifested  in  mecha¬ 
nisms  throughout  the  network,  including:  host  computer 
operating  systems,  network  managers,  trafTc  shapers, 
schedulers,  routers,  switches  and  combinations  thereof.  As 
these  mechanisms  are  distributed  and  are  often  obscurely 
related,  there  has  been  some  interest  in  the  ability  to 
express  and  quantify  the  level  of  support  for  security  policy 
and  Quality  of  Security  Service  (QoSS:  managing  security 
and  security  requests  as  a  responsive  “service”  for  which 
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Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
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quantitative  measurement  of  service  “efTciency”  is  possi¬ 
ble)  provided  in  networked  systems. 

The  purpose  of  this  paper  is  to  present  the  system  devel¬ 
oped  for  the  MSHN  resource  management  system  [8]  for 
describing  network  security  policy  functional  require¬ 
ments,  to  show  how  QoSS  parameters  and  mechanisms  can 
be  represented  in  such  a  system,  and  to  provide  an  example 
of  the  use  of  this  system.  The  remainder  of  this  paper  is 
organized  as  follows.  Section  2  discusses  a  “security  vec¬ 
tor”  for  quantifying  functional  support  of  network  security 
policy.  Section  3  describes  how  the  security  vector  can  be 
used  for  expressing  the  effects  of  QoSS  in  a  network¬ 
scheduling  beneTt  function;  and  a  conclusion  follows  in 
Section  4. 

2  Network  Security  Vector 

A  network  security  policy  can  be  viewed  as  an  n-dimen- 
sional  space  of  functional  security  requirements.  We  repre¬ 
sent  this  multidimensional  space  with  a  vector  (S)  of 
security  components.  Each  component  (S.c)  speciTes  a 
boolean  functional  requirement,  whereby  the  instantiation 
of  a  network  job  either  meets  (possibly  trivially)  or  does 
not  meet  each  of  the  requirements.  By  convention,  a  secu¬ 
rity  vector’s  components  are  ordered,  so  they  can  be  refer¬ 
enced  ordinally  (S.3)  or  symbolically  (S.c).  A  component 
may  indicate  positive  requirements  (e.g.,  communications 
via  node  n  must  use  encryption)  as  well  as  negative  con¬ 
straints  (e.g.,  users  from  subnet  s  may  not  use  node  n). 
Components  can  also  be  hierarchically  grouped.  [22] 
Requirements  for  a  given  security  service  may  be  repre¬ 
sented  by  one  or  more  components  (indicating  a  service 
sub-vector),  and  a  security  service  may  utilize  functions 
and  requirements  of  other  services  and  their  components. 

Some  jobs  can  produce  output  in  different  formats, 
where  a  given  format  (e.g.,  high  resolution  video)  might  be 
more  resource  consumptive  than  another  format  (e.g.,  low 
resolution  video).  Formats  may  have  differing  security 
requirements,  even  within  the  same  job.  For  example,  a 
video-stream  format  may  require  less  packet  authentication 
[19]  ,  percentage-wise,  than  a  series  of  Txed  images  based 
on  the  same  data.  A  “quality  of  service”  scheduling  mecha¬ 
nism  might  choose  one  format  for  a  job  over  another, 
depending  on  varying  network  conditions  (e.g.,  traffc  con¬ 
gestion).  Further,  adaptive  applications  may  select  formats 
depending  upon  changing  conditions.  For  example,  IPSec, 
security  association  (SA)  processing  using  ISAKMP  under 
IKE  can  permit  complex  security  choices  through  an  SA 
payload;  and  the  payload  recipient  may  be  given  transform 
choices  regarding  both  Authentication  Header  and  Encap¬ 
sulating  Security  Protocol  [13]  . 


2.1  Notation 

The  set  of  all  jobs  is  represented  by  J.  The  set  of  all  for¬ 
mats  is  represented  by  I.  The  notation  Sjj  identiTes  a  vector 
containing  the  portions  of  S  that  are  applicable  to  job  j  in 
format  i,  and  Sij.c  identiTes  a  given  component  (c)  of  Sjj. 
The  relation  of  S  to  Sjj  is  clariTed  further,  below.  The  fol¬ 
lowing  are  some  informal  examples  of  security-vector 
components: 

*  S.  1 :  user  access  to  resource  is  equal  to  read/write;  based 
on  table  t 

*  S.2:  %  of  packets  authenticated  >=  50,  <=  90;  inc  10 

*  S.3:  clearance  (user)  =  secrecy /integrity  (resource) 

*  S.4:  length  of  conTdentiality  encryption  key  >=  64,  <= 
256;  inc  64 

*  S.5:  authentication  header  transform  in  {HMAC-MD5, 
HMAC-SHA} 

*  S.6:  packets  from  domain  A  to  domain  B  must  be 
encrypted 

*  S.7:  packets  from  domain  A  cannot  be  sent  through 
domain  C 

Here,  “inc  10”  indicates  that  the  range  from  50  through 
90  is  quantized  into  increments  of  10,  viz:  50,  60,  70,  80, 
90.  Later,  we  will  need  to  indicate  the  number  of  quantized 
steps  in  the  component;  to  do  this,  one  more  notational  ele¬ 
ment  is  introduced,  [5.c].  In  the  above  examples,  [5.7]  =  1, 
and  [5.2]  =  5. 

2.2  Variant  Security  Components 

When  [S.c]  >  1,  the  underlying  control  program  has  a 
range  within  which  it  may  allow  the  job  to  execute  with 
respect  to  the  policy  requirement.  We  refer  to  this  type  of 
policy,  and  component,  as  “variant.”  Security-variant  poli¬ 
cies  may  be  used  within  a  resource  management  context, 
for  example,  to  effect  adaptation  to  varying  network  condi¬ 
tions.  [18]  Also,  if  the  policy  mechanism  is  variant,  the 
control  program  may  offer  QoSS  choices  to  the  users  to 
indicate  their  preferences  with  respect  to  a  given  job  or 
jobs.  Without  variant  mechanisms,  neither  security  adapt¬ 
ability  by  the  underlying  control  program  nor  QoSS  are 
possible,  since  Txed  policy  mechanisms  do  not  allow  for 
changes  to  security  within  a  Txed  job/resource  environ¬ 
ment.  While  the  expression  S.c  may  contain  a  compound 
boolean  statement  (see  Section  2.3  ),  by  convention  it  may 
contain  only  one  variant  clause. 


2.3  Component  Structure 

For  use  in  the  examples  in  this  discussion,  a  component 
has  the  following  composition  (see  Table  1  for  details): 

•  component  ::=  boolean  expression,  variant-range-spec- 
iTer ;  modifying-clause 

•  boolean  _expression  ::=  boolean_statement  [(or  I  and) 
boolean_statement]  * 

•  boolean_statement  ::=  LHS  boolean-operator  RHS 

Note  that  it  is  not  the  focus  here  to  elaborate  on  a  policy 
representation  language.  See  other  efforts  and  works  In 
progress  [2]  [3]  [5]  [16]  . 

A  given  policy  component  has  a  value  which  is  a  bool¬ 
ean  expression.  This  component  may  also  have  an  instanti¬ 
ated  value  with  respect  to  a  speciTc  job  and  format,  which 
is  either  “true”  or  “false.”  A  component  has  a  left  hand  side 
(LHS),  which  is  the  item  that  is  being  tested;  of  course  the 
LHS  has  a  value  as  well  as  an  instantiated  value.  A  compo¬ 
nent  also  has  a  right  hand  side  (RHS),  which  is  what  the 
LHS  is  tested  against,  as  well  as  zero  or  more  modifying 
clauses.  Similarly  to  the  LHS,  the  RHS  may  have  a  value 
(or  values)  which  is  dependent  on  the  instantiation  of  the 
component. 

2.4  Dynamic  Security  Policies 

With  a  dynamic  security  policy,  the  value  of  a  vector's 
components  may  depend  on  the  network  “mode”  (e.g.,  nor¬ 


mal,  impacted,  emergency,  etc.),  where  M  is  the  set  of  all 
modes.  There  is,  conceptually,  a  separate  vector  for  each 
operational  mode,  represented  as:  Access  to  a  pre¬ 

defined  set  of  alternate  security  policies  allows  their  func¬ 
tional  requirements  and  implementation  mechanisms  to  be 
examined  with  respect  to  the  overall  policy  prior  to  being 
Telded,  rather  than  depending  on  ad  hoc  methods,  for 
example,  during  an  emergency. 

Initially,  every  component  of  S  has  the  same  value  in 
each  of  its  modes.  Ultimately,  components  may  be 
assigned  different  values,  depending  on  the  network  mode. 
For  example: 

.  ^nornml^^.  ^  packets  authenticated  >=  50,  <=  90;  inc  10 

.  ^impacted packets  authenticated  >=  20,  <=  50; 
inc  10 

Note  how  [5.a]  changes  from  5  to  4  under  the 
impacted  mode 

.  ^normal  access  to  network  node  =  granted;  based 

on  table  t 

.  g impacted  1^.  access  to  network  node  =  granted; 
based  on  table  t,  OR  UID  in  set  of  administrators 

.  ^emergency  {administrators,  policymak¬ 

ers} 

Or,  for  example,  policy  makers  might  decide  that  the 
policy  should  remain  in  force  regardless  of  network  mode: 

.  ^normal ^  ^impacted ^  ^emergency dgarance  (user) 
=  classiTcation  (resource) 


Table  1 :  Simple  Component  Elements 


Element  Name 

Example  S.l 

Example  S.2 

Value 

user  access  to  resource  r  =  RW,  based 
on  table  t 

%  of  packets  authenticated 
>=  50,  <=  90;  inc  10 

Instantiated  value 

false 

true 

Value  of  LHS 

user  access  to  resource  r 

%  of  packets  authenticated 

Instantiated  value  of  LHS 

W 

70 

Boolean  operator 

= 

>= 

Value  of  RHS 

RW 

50 

variant  range  speciTer 

none  applicable 

<=  90 

Modifying  clause 

based  on  table  t 

inc  10 

If  a  mode  is  not  speciTed  for  a  component  (e.g.,  “S.a”), 
normal  mode  is  assumed.  This  will  be  the  case  (i.e.,  the 
mode  is  unspeciTed)  for  the  remainder  of  this  discussion. 

2.5  Refinements  to  Security  Vector 

R  is  the  set  of  resources  {rj..  r„}.  R^j  is  the  subset  of  R 
utilized  in  executing  job  j  in  format  i. 

Tj  is  the  requested  completion  time  of  job  j. 

Security  policies  may  be  expressed  with  respect  to  prin¬ 
cipals  (user,  group  or  role,  etc.,),  applications,  data  sets 
(both  destination  and  source),  formats,  etc.,  as  well  as 
resources  in  Rjj. 

The  deTnition  of  is  Tnally  reTned  as  follows:  Sjj  is  a 
vector  that  is  an  order-preserving  projection  of  S,  such  that 
a  component  c  from  S  is  in  5^  if  and  only  if  the  value  of  c 
depends  on  format  i,  job  j,  or  any  r  in  Rij.  The  number  of 
components  in  a  security  vector  is  [5^]. 

2.6  Summary  of  Security  Vector 

5  is  a  general  purpose  notational  system  suitable  for 
expressing  arbitrarily  complex  sets  of  network  security 
mechanisms.  S  can  express  variant  policies,  to  allow  secu¬ 
rity  expressions  of  quality  of  service  requests,  and  can  have 
dynamic  security  elements  to  accommodate  multiple  situa¬ 
tion-based  policies.  In  particular,  S  can  represent  both  (1) 
static  security  requirements  that  may  be  implemented  in  a 
system,  as  well  as  (2)  the  results  of  running  a  particular  job 
or  set  of  jobs  against  such  static  requirements.  The  latter 
usage  will  be  examined  in  the  next  section,  to  express 
QoSS  in  a  resource  management  system  beneTt  function. 

3  Network- Scheduler  Benefit  Function 

As  discussed  above,  various  mechanisms  exist  for  man¬ 
aging  contention  for,  and  allotment  of  distributed  network 
resources.  One  class  of  these  mechanisms  attempts  to  efT- 
ciently  schedule  the  execution  of  multiple  (possibly  simul¬ 
taneous)  jobs  on  multiple  distributed  computers  (e.g.,  the 
MSHN  project  [8]  [23]  [24]  [11]  [17]  ),  where  each  job 
requires  a  determinable  subset  of  the  resources.  Of  interest 
is  a  beneTt  function  for  comparing  the  effectiveness  of 
such  job  scheduling  mechanisms  when  they  are  presented 
with  real  or  hypothetical  “data  sets”  of  jobs. 

Jobs  are  assigned  priorities  for  use  in  resolving  resource 
contention  and  allocation  issues.  In  some  systems,  a  job’s 
priority  may  depend  upon  the  particular  operating  mode  of 
the  network.  [8]  Also,  the  different  data  formats  of  a  multi¬ 
ple-format  job  may  have  different  preferences  (e.g., 
assigned  by  a  user  or  “hard  wired”  as  part  of  the  applica¬ 
tion  or  job-scheduler  database),  and  different  levels  of 


resource  usage.  [10]  [12]  A  network  job  scheduler  should 
receive  more  credit  in  the  beneTt  function  for  scheduling 
high  priority  and  high  preference  jobs,  as  opposed  to  low 
priority  or  low  preference  jobs.  That  is  to  say,  a  scheduler 
is  intuitively  doing  a  better  job  if  important  jobs,  as  judged 
by  priority  and  preference,  receive  more  attention  than 
unimportant  jobs.  How  much  weight  the  priorities  and 
preferences  are  given  is  a  matter  of  network  scheduling 
policy. 

For  illustration,  we  introduce  a  simple  beneTt  function, 
B,  to  measure  how  well  a  scheduler  meets  the  goals  of  user 
preference  and  system  priorities  (see  [4]  ,  [12]  and  [21] 
for  other  approaches).  This  function  averages  preference 
ip)  and  priority  (P)  (use  of  a  priority  and  preference  in 
measuring  network  effectiveness  have  been  introduced  for 
the  MSHN  project  [10] ). 

n  nij 

B=  =  ^ - 

2n 

Where  the  characteristic  function  X  is  deTned  for  i,  j  as: 

Xij  =  1  if  format  i  was  successfully  delivered  to  job  j 

within  time  Tj,  else  0 

and  at  most  one  format  is  completed  per  job: 

Jobs  and  formats  are  deTned  as  above. 

Pj  is  the  priority  of  job  j 

O.Pj.l 

The  formats  for  a  job  are  assigned  preferences  (p)  by 
the  user  such  that: 

0  <=  j!7<=  1 

mj  is  the  number  of  {format,  preference}  pairs 

assigned  for  job  j 

Pjj  is  the  preference  the  user  has  assigned  to  format  i, 

jobj 

the  preferences  for  a  job  add  up  to  1 : 

ntj 

i  =  1 

This  approach  assumes  that  users  will  assign  preference 
values  that  correspond  to  resource  usage,  since  we  want  the 
beneTt  function  to  indicate  a  higher  value  when  the  sched¬ 
uler  succeeds  in  scheduling  “harder”  jobs  [12]  . 


3.1  Adding  Security  to  the  Benefit  Function 

We  wish  the  beneTt  function  to  retect  the  ef  fectiveness 
and  restrictions  of  the  security  policy.  First,  we  deTne  the 
characteristic  security  function  Z,  for  i  and  j: 

Z,y  =  1  if  the  instantiated  value  of  all  components  in  Sij 
are  true,  else  0 

The  numerator  of  the  beneTt  function  is  multiplied  by  Z, 
so  that  no  credit  is  given  for  jobs  that  fail  to  meet  the  secu¬ 
rity  requirements: 

n  nij 

B=  ^  1 - 

2n 

Now,  for  variant  components,  we  wish  to  be  able  to  give 
less  credit  to  the  scheduler  for  fulTlling  less  “difTcult” 
security  requirements.  One  algorithm  for  expressing  this  is 
for  each  instantiated  component  (c)  in  to  be  assigned  a 
security  completion  token  (g)  where  0  <  g  <  1  .  will 
indicate  the  completion  token  corresponding  to  component 
S.c.  is  deTned  to  be  the  “percentage”  of  [5.c]  met  or 
exceeded  by  the  instantiated  value  of  the  component’s 
LHS  (notated  as  5.c”): 
g,  =  5.c”/[5.c] 

To  illustrate  the  calculation  of  g;,  for  component  S.l: 

S.l  :  %  of  packets  authenticated  >=  50,  <=  90;  inc  10 
[5.7]  =  5  (the  number  of  quanta  in  S.l),  S.l”  =  3  (the 
job  achieves  the  3rd  quantum  (70)) 
gj  =  3/5  =  0.6 

For  invariant  components,  g  =  1  or  g  =  0.  A  token  (g) 
whose  value  is  0  represents  a  job  “failing”  the  component’s 
security  policy.  Recall  that  Z  will  be  0  when  the  job/format 
fails  to  meet  the  requirement  of  any  security  component, 
meaning  that  the  function  returns  no  beneTt  value  for  that 
job/format.  We  introduce  a  function  (A)  which  averages  the 
tokens  of  a  job: 

AiJ  =  (gj+g2  +  -+  gn)ln 

where  n  =  [5,y]  —  the  number  of  components  in  Sij 
and  (0  <  A  .  .  <  1) 

Averages,  such  as  A,  over  many  different  elements  can 
tend  to  minimize  the  difference  that  is  seen  between  differ¬ 
ent  data  sets.  Therefore,  we  weight  the  tokens  (g)  assigned 
to  individual  security  components  to  give  more  credence  to 
components  that  are  “more  important”  than  others,  e.g., 
rejecting  netw  ork  management  policies.  Each  g„  has  a  cor¬ 
responding  integer  weight  (w„),  >  0  .  So  Aij  becomes: 

^ij  =  (gl^l  +  g2^2  +  •■  +  gn'^n)^(^l  +  ^2  +  ..  +  wj 


again  (0  <  A-j  <  1 ) 

In  the  Tnal  expression  of  the  network  beneTt  function,  A 
is  added  to  the  numerator,  providing  an  average  of  security, 
priority  and  preference. 

n  nij 

B=  ■/  =  1  =  1 - 

3n 

0  <  B  <  I  ,  where  1  indicates  the  maximum 
scheduling  effectiveness. 

3.2  Applicability 

This  technique  for  quantifying  the  variant  security 
instantiated  by  a  resource  management  system  is  being 
used  in  the  MSHN  project  as  a  factor  in  representing  the 
effectiveness  of  its  resource  assignments  [10]  .  In  the 
MSHN  design,  the  security  requirements  of  network 
resources  (represented  by  S)  are  stored  in  a  Resource 
Requirements  Database.  This  database  is  consulted  during 
the  resource  scheduling  phase  to  effectively  match  jobs  to 
resources.  We  expect  that  this  measurement  technique 
could  also  be  applied  to  other  resource  management  sys¬ 
tems,  such  as  Condor  [15]  and  Globus  [7]  . 

While  different  schedulers  could  be  compared  with 
respect  to  the  individual  components  of  B,  a  summary 
function  such  as  B  would  be  useful  to  automate  and  nor¬ 
malize  the  comparison  process.  Additionally,  we  expect 
that  the  security  component  (viz.  A)  in  an  operational  sys¬ 
tem  would  be  complex  enough  to  evade  effective  manual 
analysis. 

4  Discussion  and  Conclusion 

A  security  vector  has  been  presented  for  describing 
functional  requirements  of  network  security  policies.  It  has 
been  shown  that  this  vector  can  be  used  for  representing 
security  with  respect  to  both  quality  of  service  and  a  net¬ 
work  scheduler  beneTt  function. 

We  are  involved  in  ongoing  work  to  organize  the  secu¬ 
rity  vector  into  a  “normal  form”  with  sub-vectors  or  hierar¬ 
chies  corresponding  to  security  policy  jurisdictions  (such 
as:  access  control,  auditing,  and  authentication)  and  to 
incorporate  a  costing  methodology  for  security  compo¬ 
nents,  such  as  can  be  provided  to  a  resource  management 
system  [9]  .  We  are  working  to  develop  a  means  of  adjust¬ 
ing  the  preference  expression  with  a  notion  of  the  corre¬ 
sponding  resource  usage  [12]  .  We  are  considering  how  to 
expand  the  security  beneTt  function  (A)  to  retect  user  qual- 


ity  of  security  service  choices  within  the  range  allowed  by 
variant  security  components,  and  to  retect  performance 
implications  of  redundant  security  mechanisms. 

The  organizational  security  policy  [20]  governing  the 
network  may  allow  individuals  or  principals  representing 
them  to  override  rules  represented  by  invariant  security 
vector  components.  For  example,  a  military  commander 
might  decide  to  forgo  cryptographic  secrecy  mechanisms 
for  a  job  in  an  emergency  (e.g.,  to  improve  network  perfor¬ 
mance),  even  though  the  system  has  not  been  conTgured 
with  “dynamic”  or  “variant”  security  mechanisms,  as 
deTned  herein.  From  the  perspective  of  the  security  vector 
S  and  the  beneTt  function,  this  is  a  change  to  or  violation 
of  the  computer  security  policy.  It  is  recommended  that  this 
type  of  policy  change  be  audited. 
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